对话 | 谷歌VP谈工程生产力（二）

本文是《谷歌VP谈工程生产力》的第二部分记录。

背景介绍：

---

Engineering Excellence ，就是“工程卓越”，这一提法最早似乎来自微软。而Engineering Productivity，中文译为“工程生产力”（并非效率）。据我有限的知识，在软件行业内，将EP正式引入组织的企业是谷歌。

2016年3月，谷歌将原来的质量保障团队（QA or Testing）正式更名为“工程生产力团队”。详情见文末的“原文链接”。

Michael Bachman加现在是谷歌的Engineering VP，之前是Senoir Director。他加入Google 有16年之久，是这个部门的最早员工。

下面是他在2018年4月的一个社区交流会上的分享记录。

第二部分的PPT如下：

需要获得完整PPT内容，请关注公众号“持续交付2.0”，留言“EP-PPT”。

问答记录（第二部分）：

---

1、谷歌有多少生产线的回滚？

    这取决于哪些线上服务、负责该服务的团队的成熟度，以及他们对问题的忍受度。如果业务还是刚起步，那么，只要确保团队自己真正理解他们在做什么，想要快速迭代试验。那么，我们也不管。但是对于那些数十亿的业务，我们不会这么干的。

2、对于生产线上出现的问题，EP团队会充当什么角色？

SRE团队会负责处理Pager（就是值班On-call），另外的团队需要思考“如何弥补这类问题的Gap，设法消除它们。”

3、如此多的编程语言、操作系统、不同的构建过程、测试过程和发布过程，谷歌是如何处理这些数据，以便用来指导生产过程优化的呢？

首先，这些度量指标数据要有统一的模型和统一的存储。之后，才有可能统一分析研究。所以，各类数据应该统一抽象建模。我们以Javascript为例。如果有一个服务是Javascript写的，它可能没有非常完整的pipeline，可能只有完整Pipeline中的环节。但我们仍旧会将其数据写入对应的环节数据中。

4、是否可以详细介绍一下谷歌内部所用的数据模型？

恐怕现在不行。谷歌在整个行业还没有苏醒时就开始做这件事。到目前为止，也积累了一些内容。随着不断的共享开放，我希望不久的将来可以公布。

5、谷歌如何可视化这些数据，以便让团队可以发现关键的，并改进之？

我们也有几个通用的数据指标，例如：（1）多快速地发布到生产环境？（2）频率是什么样的？（3）回滚的数量是多少？（4）生产环境发生了多少pager issue。等等……

我们也有自己定义的项目健康标尺（bar）。例如我们分了五级。一级可能是有一定的验收条件、一定的速度、一定的稳定性等。使团队更有目标方向。我们在整个公司发布了这个模型，通常这个模型应该比较简单易用，这样让团队有目标。例如，团队可能会说，“看，我们现在已经达到了上线速度的一级要求，下一个目标是什么？”

6、如何说服其他团队使用你做出来的工具呢？你会直接强制要求他们使用么？

“强制大家使用工具”太重了，尤其是在google，是很难的，大多数工具是自下而上的。早期的测试团队用过那种“扔过墙”模式。开发人员非常抵触。你应该和他说：“看看你现在的生产力问题，有哪些挑战，从而构建一些共识”。如果他们没有理你，你也可以试一试别的方式。这种排斥反应是很自然的。也许是你根本没有理解他们的工作流程，他们需要什么，他们的优先级是什么？如果你了解，你就应该构建一些他们真正在意的工具。

7、如何选择执行哪些测试？

我们会看测试在一段周期内的ROI，比如测试的稳定性。提交后的测试是全量的，当然，那些不稳定的测试是分离出去的。

8、谷歌做静态扫描么？

当然要做。

9、EP团队现在有考虑“现在应该开始做什么了？或者某个事情在前几年就应该做了？”这类的思考总结么

工程师是有限资源。难点在于决策做哪些和不做哪些。我们有时候会停止一些工具的开发，但那些工具在决定开发时，可能是高优先级的。但现在可能不再是了。

我仍旧认为移动开发是难点。iOS开发更难一些。比如，如何处理与硬件的接口。有一些很难模拟。

10、你们是否使用公司统一的工具，还是开发很多定制化的工具呢？

我说过，我们有一个横向团队，我们尝试着统一一些工具，但挑战是谷歌的文化。你会听道工程师说：“我想创新，我想自己构建自己用的工具。”，或者“我有10%的需求，这个工具无法满足。我自己构建一个吧”。还有就是，他一旦依赖你的工具，而你的迭代速度又不够快。这是很常见的问题啦。

另外，我们的团队没有产品经理，所以工程师试着构建这些工具。

11、谷歌使用很多试验方式发布产品（A/B, 灰度等技术）。EP团队也用这种方式发布自己的工具么？

我们也做了很多试验。谷歌有4~5万工程师，我们也会发布给1%的工程师使用。然后看看这些工具会不会改变我们前面提到的那些度量指标。例如如，前面我提到的那个“不执行那些没有影响的自动化测试用例”项目。

重磅推荐

《持续交付2.0》

硅谷顶级互联网公司的产品研发方法。

在未来十年里，

快速提升工程生产力，打造有战斗力的团队，

应对激烈的市场竞争，

这一本书就够了~

《持续交付2.0：业务引领的DevOps精要》

扫码购买

京东 77.5元

本书“重新定义”了持续交付，增补了组织管理和架构两个维度，辅助以真实案例，对诸多持续交付的原则和实践加以解读，并对持续交付过程中的取舍原则加以论述。 

持续交付2.0是实现组织战略目标的组织能力，并引入双环模型理论，以及基础工作原则、组织原则和架构原则；

通过多个互联网公司案例的解读，阐述如何根据组织的当前状况，应用原则，并对最佳实践进行取舍，快速达到组织能力目标。

关于作者

乔梁

持续交付2.0 创始人

专注于软件企业组织管理

DevOps顶级大神

著有《持续交付2.0》

译有《持续交付》《软件沉思录》

关注公众号查看其他原创作品